Method and apparatus for resolving energy imbalance requirements in real-time

ABSTRACT

A method and apparatus for resolving energy imbalance in a real-time manner is disclosed. A plurality of market user interfaces are coupled to an imbalance engine which determines optimal dispatch requirements corresponding to supply and demand requirements of the market participants. The imbalance engine resolves in a real-time manner the dispatch requirements while considering the transmission limitations, ramping limitations, transmission facilities, and price data.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit under 35 U.S.C. §119(e) ofU.S. Provisional Application No. 60/338,424 filed on Dec. 7, 2001 whichis herein incorporated by reference.

TECHNICAL FIELD

[0002] This invention relates generally to a method of generating theenergy required to provide balancing energy to certain regions based onthe availability of the generating resources within RegionalTransmission Organizations. In particular, the invention pertains togenerating and resolving energy imbalance requirements for RegionalTransmission Organizations, Independent System Operators, andIndependent Transmission Providers.

BACKGROUND ART

[0003] A brief description of how the energy imbalance market functions,as required by the Federal Energy Regulatory Commission (“FERC”)regulations, may be helpful in understanding the field of the presentinvention. In April 1996, FERC Order 888, “Promoting WholesaleCompetition Through Open Access Non-discriminatory Transmission Servicesby Public Utilities,” required jurisdictional public utilities to fileopen access transmission tariffs to allow competition in the supply ofwholesale electrical energy. Under the Order 888 market entities(utilities, merchant generators, energy traders, etc) compete to provideenergy based on several factors including cost and availability oftransfer capacity on transmission facilities. Market entities can belimited from providing energy to certain regions based on theavailability of transfer capacity on transmission facilities.

[0004] According to the framework established by Order 888, provision ofenergy to resolve imbalances in the actual production of energy versusscheduled energy was the responsibility of the Transmission Provider andwas covered as part of the Open Access Tariff. The Transmission Providerusually satisfied this requirement without a market mechanism byself-generating the required balancing energy.

[0005] In December 1999, FERC issued Order 2000, “Regional TransmissionOrganizations.” This order required jurisdictional public utilities toform and participate in a Regional Transmission Organization (“RTO”).The operational control of generators, and transmission facilities wasassigned to the Regional Transmission Organization. Under FERCregulations, RTOs are required, among other things, to ensure that itstransmission customers have access to a real time balancing market. AnRTO may cover parts of one or more states within the United States. RTOsare required to maintain efficient traffic grid management, to improvegrid reliability, to monitor and mitigate against opportunities fordiscriminatory transmission practices, and to improve competition in thewholesale electricity markets. The RTO is expected to administer theopen access transmission tariff, to exercise operational control over,congestion management, reliability and to plan the expansion of itstransmission system. An additional set of requirements for RTOs are thatthey remain independent of the market participants.

[0006] In the framework of FERC Order 2000, the RTO is responsible forproviding transmission customers with access to a real time balancingmarket. Several market operators met the requirements of this order byredispatching all energy in a real time market, followed by financialsettlement of energy imbalances. The requirements of this order can alsobe met by the imbalance engine described below.

[0007] In July 2002, FERC issued a Notice of Proposed Rulemaking (NOPR),“Remedying Undue Discrimination through Open Access Transmission Serviceand Standard Electricity Market Design.” This NOPR announces FERC'sintent to form a standard market design for wholesale electrical energy.This NOPR requires public utilities to place their transmission assetsthat are used in interstate commerce under the control of an IndependentTransmission Provider or ITP. Among other functions, an ITP isresponsible for operating a day ahead market and a real time market forbalancing energy.

[0008] In the day ahead market, spot market prices are generallydetermined based on offers to supply energy and on forecast requirementsfor load. A supply curve is determined using either marginal costs orbid prices to rank order the plants beginning with the cheapest plants.However, the FERC NOPR recognizes that to create a truly competitivewholesale power market, the market must also allow for price responsiveloads.

[0009] In this framework, the market operator receives pricinginformation from various wholesale market generators (typicallycoal-fired power plants, hydroelectric power plants, nuclear powerplants, etc.) and receives energy requirements information from the LoadServing Entities. The market operator is then responsible fordetermining an operating plan based on the offers provided by thevarious market generators and the bids provided by the various LoadServing Entities in the most cost effective manner.

[0010] Presently, all generators provide schedule information to controlarea operators in the form of a statement of quantity of energy theyplan to generate and the time at which the energy will be generated. Theamount of energy may vary over the course of a day, changing typicallyin hourly increments based on a variety of factors. Under the frameworkof Order 2000 and the FERC NOPR, market participants may voluntarilyoffer to supply additional energy beyond the predetermined scheduledamount or alternatively to reduced the energy supplied below thepreviously scheduled amounts so that the RTO satisfy real time balancingrequirements. Additional energy costs arise when the market generator isrequested to meet a real-time and unanticipated shortage of energy.Additionally, reduced energy costs may arise when the market generatoris requested to provide less energy than previously contracted for inorder to meet an unanticipated glut of energy.

[0011] Computer systems within an RTO (Regional TransmissionOrganization, Independent System Operator, or Independent TransmissionProvider) generate an daily operating plan that determines for each timeincrement for the following day how much energy will be supplied by eachgenerator. The energy needs are forecast for each day based on knownstatistical methods of forecasting electrical demand. The forecast istypically accurate but is seldom one hundred percent accurate as to theenergy demands for a certain region. Accordingly, as the energy planfrom the previous day is carried out by the RTO, the energy demands arenot one hundred percent accurate. More or less energy is actually neededthan that which was in the energy plan, and there may be deficiencies inthe amounts of energy actually supplied by generators due to forced orunplanned outages for maintenance. This variance in energy requirementsis referred to as imbalance energy or balancing energy requirements TheRTO computer system addresses that imbalance by using the bid and offerinformation received from market participants.

[0012] The RTO is required by the FERC Order 2000 to implement an energyimbalance market. The imbalance market requires a real-time market forbidding to provide energy generation and load adjustments to satisfy theimbalance. Therefore, instead of relying on contracted prices generatedone or more days in advance, a method must be provided to allow marketgenerators and loads to bid for adjustments (for example, by providingmore or less energy) in a real-time manner during the day in real timeas the energy imbalance occurs.

[0013] The imbalance market uniquely requires a real-time market forbidding and for providing the energy generation adjustments required tosatisfy the imbalance. The present invention address the above notedneeds by providing a real-time imbalance engine to support and implementthe equitable imbalance requirement via a computer systemimplementation. The imbalance engine enables the RTO to operate a loadfollowing scheme to implement the FERC 2000 and NOPR requirements forimplementation of an equitable energy imbalance market. The imbalancemarket mechanism assures a means other than the use of dedicatedregulation and reserve resources or bilateral contract markets tobalance load and generation. Additionally, the present invention allowsthe market generators and loads to provide electronic bids forresolution by the imbalance engine.

SUMMARY OF THE INVENTION

[0014] According to one aspect of the invention, there is provided asystem for balancing the load requirements for energy imbalance in anenergy trading market, said system comprising: a plurality of marketuser interfaces, each market user interface receiving from a pluralityof market participants supply and demand requirements for imbalanceenergy; and an imbalance engine coupled to said plurality of market userinterfaces for determining optimal market dispatch corresponding to saidsupply and demand requirements.

BRIEF DESCRIPTION OF THE FIGURES

[0015] The present invention will now be described with reference to theaccompanying drawings wherein:

[0016]FIG. 1 is a schematic diagram of the implementation of a real timeimbalance engine in accordance with the principles of the presentinvention;

[0017]FIG. 2 is an exemplary block diagram of the components andinterfaces of the imbalance engine in accordance with the principles ofthe present invention;

[0018]FIG. 3 is a time-line of the operation of the imbalance engine;

[0019]FIG. 4 is a time-line of the operation of the imbalance engine;

[0020]FIG. 5 is a schematic diagram of the operation of a real-timemarket for any resource;

[0021] FIGS. 5(a) and 5(b) are graphs of balancing energy prices versusbalancing energy quantity;

[0022]FIG. 6 is a graph of price versus MW;

[0023]FIG. 7 is a graph of MW versus time;

[0024]FIG. 8 is a graph of MW versus time;

[0025]FIG. 9 is a graph of price versus MW;

[0026]FIG. 10 is a graph of price versus MW;

[0027]FIG. 11 is a graph of price versus MW;

[0028]FIG. 12 is a graph of price versus MW;

[0029]FIG. 13 is a graph of price versus MW;

[0030]FIG. 14 is a graph of price versus MW;

[0031]FIG. 15 is a graph of price versus MW;

[0032]FIG. 16 is a graph of price versus MW;

[0033]FIG. 17 is an object oriented view of the data model to be used bythe imbalance engine of the present invention;

[0034]FIG. 18 is shown a schematic diagram of the relationship betweenthe imbalance engine database and the interface databases; and

[0035]FIG. 19 is a common structure of data interfaces.

DETAILED DESCRIPTION OF THE FIGURES

[0036] To illustrate the principles of the present invention, areal-time imbalance engine developed by Siemens Power Transmission &Distribution, Inc., the assignee of the present invention, shall bedescribed in detail. While this engine constitutes a preferredembodiment of the invention, it is not the intention of applicants tolimit the scope of the invention to the particular details of thisengine. Rather, it is the intention of the applicants that the inventionbe defined by the appended claims and all equivalents thereto.

[0037] The imbalance engine seeks to assure a means, other than the useof operating reserve and regulation resources or bilateral contractmarkets, to balance load and generation. The present invention allowsthe market generators and loads to provide electronic bids forresolution by the imbalance engine via an electronic interface. Thepresent invention includes features such as: (1) providing loadfollowing service; (2) improving economic efficiency of energydeliveries in the RTO region; (3) minimizing the capacity required forregulation; (4) improving control performance of the control areas in anoptimum manner; and (5) providing key coordination capabilities in anequitable manner for the control areas within the RTO region.

[0038] In one embodiment of the present invention, all balancing energybids and offers are evaluated and cleared through the imbalance marketengine of the present invention. The imbalance market engine supportsoptimal imbalance market operation, while actual implementation ofbalancing energy dispatch will be provided by control area energymanagement systems (“EMS”) which control the physical operation of thegenerating units and price responsive loads within the RTO. It should benoted that a control area is a geographical area within the RTO region.Imbalance market dispatch instructions issued from the imbalance engineare treated as directions to improve control area efficiencies throughoverall RTO optimization.

[0039] In an alternative embodiment of the present invention, the RTOmay operate as a both a transmission provider and a virtual controlarea. In this embodiment, the imbalance engine may use existing orconventional energy management system controls to adjust generationoutput of those generators willing to adjust output in this manner forcompensation via balancing energy pricing. The imbalance market enginerelies on the existing or conventional EMS systems and their associatedcontrol systems for implementation of imbalance signals. The ImbalanceEngine also sends a dynamic schedule to its associated EMS systems thatrepresent individual purchase or sale of imbalance energy. Theseschedules represent set points in the imbalance market and the unitswill be expected to follow those signals in a controlled and reasonablypredictable manner.

[0040] As stated previously, the imbalance market is operated by an RTO.The RTO manages a region which is split into non-overlapping pricingzones. RTO pricing zones are generally static and are coincident withRTO control areas. For instance, each pricing zone will consist of oneor more network nodes.

[0041] Generator balancing energy bids indicate a market generator'swillingness to deviate from the previously established schedule and tooperate his unit at a specific output in return for specificcompensation. There is no obligation of a generator to submit balancingenergy bids or to follow bid curves (for example, participation in theRTO energy imbalance market is voluntary). However, there is anexpectation that market generators who do bid and receive awards, willfollow their bid obligations in a predictable manner. Other generatorsare expected to operate according to their previously establishedschedules.

[0042] Any load (for example, a consumer of electrical energy) can alsoparticipate in a similar manner as generators to the extent that theymeet the same metering requirements and can reliably vary the load. Theload will participate on an equal basis with market generators sourcesafter some consideration for transmission losses.

[0043] The imbalance engine automatically accounts and adjusts fortransmission losses. The imbalance engine is integrated across allinternal RTO control areas or pricing zones, and dynamically schedulesenergy across these control areas to minimize the differences in zonalimbalance prices. The inadvertent energy will be priced at balancingenergy prices. The money and energy accounts for each control area willbe established as a part of a settlement system. Therefore, there are nodirect needs to consider inadvertent energy as a part of imbalanceenergy requirements during imbalance market dispatch.

[0044] Balancing energy bids (for example, bids required to supplyunplanned requirements or reduce for unplanned gluts) are submitted bymarket generators for each quarter hour increment. The same bid can besubmitted and stand for several hours. If a bid is not submitted thenthe market generator will not be considered. Bids cannot be entered oradjusted after twenty minutes before the operational fifteen minuteperiod. The submitted bids will be used during the operational 15 minuteperiod without adjustments.

[0045] In a preferred embodiment, the imbalance engine is operated everyfive minutes for real-time adjustments to the imbalance requirements.The dispatch instructions are issued two or three minutes (or someappropriately adjustable lead time) before the operational five minuteinterval. Every execution will perform optimal imbalance dispatch forthree future five minute intervals for a full fifteen minute period oftime. It will be understood that the time period intervals areadjustable, limited only by the market generator's operational abilityto ramp up or down their energy output. All dispatch reports will bepresented, but only the first 5 minute interval dispatch will be usedfor operational pricing and settlement purposes.

[0046] The imbalance engine of the present invention filters controlsignals so as not to operate units beyond their specified ramping orgeneration limits. In particular, each market generator has a definedability to ramp up or ramp down their energy output, and the imbalanceengine factors in those ramping and generation limits. The imbalanceengine recognizes the constraint and does not attempt to have a marketgenerator to increase or decrease its output at an impossible rate.Uninstructed deviations may be considered for penalties.

[0047] The imbalance engine determines the imbalance prices asLocational Marginal Prices for each market participant. Billingbalancing energy prices are calculated every 5 minutes in real time andintegrated over one hour for settlement purposes.

[0048] The imbalance engine has a mechanism to dynamically scheduleenergy across control areas to minimize control area Area Control Errors(“ACEs”) and maximize the performance of the control areas. The NorthAmerican Electricity Reliability Council (“NERC”) control performancestandards (CPS 1 and CPS2), and disturbance control standard (DCS) areapplicable to the individual control areas.

[0049] The imbalance engine relies on the RTO emergency backup system asthe back-up system. Therefore, the combined RTO systems will befail-safe as far as functionality. The imbalance engine will receiveadjustments to generation bids via the market user interface.

[0050] In one embodiment, the imbalance engine may operate with asignificant lag compared to conventional control and regulation systems.The imbalance engine filters out control that should be provided viaregulation units. Generally, it is expected that regulation units willprovide control over changes from real-time to several minutes ahead ofreal-time. The imbalance engine is focused on the period of time pastthe regulating time period but short enough to effectively provide loadfollowing capability.

[0051] Energy provided in the imbalance market will not be separatelycharged for transmission usage. Therefore, the real-time imbalance pricewill not include any additional transmission usage costs. A relationaldatabase may be used as the storage mechanism for the RTO imbalanceengine input and output.

[0052] The operation of the imbalance market provides a reasonablysmooth reliable load following that is accomplished with the operationof minimal regulation assets. The implementation of this market is toimprove and not degrade the ability of control areas to maintain theirCPS1 and CPS2 reliability standards.

[0053] The imbalance engine prevents the operation of the imbalancemarket from causing flow gates congestion or impacting already congestedflow gates. The imbalance engine interfaces with the control areaswithin the RTO region. The imbalance engine interface uses the controlareas within the RTO region to interface the existing real timeimbalance engine.

[0054] The imbalance engine integrates with the existing control areaEMS systems responsible for managing control area operations. Theimbalance engine employs pricing rules and settlement methodology thatprovide for payment adequacy, revenue neutrality and price stability.

[0055] In a preferred embodiment, the imbalance engine additionallyfeatures a high level of availability with protection against a singlepoint of failure and a minimum of 99.95% availability. The hardware,database and application allow for the addition and deletion of featuresand functions such as new Energy Management System (“EMS”) systeminterfaces, and expanded capability for data transfer.

[0056] Additionally, the imbalance engine features two aspects of usersecurity and privacy. The first guarantees a reliable storage mechanismto securely protect data availability and the second security featureallows a market participant to access to his own data privately withoutallowing any other market participant to view his data, or vice versa.

[0057] Turning now to the drawings in detail, wherein like numbersillustrate corresponding structure, FIG. 1, is a schematic diagram ofthe implementation of a real time imbalance engine in accordance withthe present invention. The implementation 200 consists of a plurality ofmarket participants (for example, energy generators) 20 which arecoupled to the public internet 30. Each market participant isrepresented by a computer terminal which can also be representative of auser terminal or user interface for accessing the RTO 40. The RTO isrepresented in the figure as a network host which is coupled to themarket participants 20 through the public internet. The RTO 40facilitates communication between the market participants 20 and thetransmission and generation facilities 60. Communication between the RTOand the transmission facilities may be accomplished over direct networklinks 50. It will be understood that network links 50 can be aproprietary network or a public internet.

[0058] Referring to FIG. 2, there is shown an exemplary block diagram ofthe components and interfaces of an imbalance engine 100 in accordancewith the principles of the present invention. The imbalance engine 100consists generally of a market user interface 102, an energy imbalanceforecast engine 104, a component for handling energy measurementsprocessing, archiving and accounting 106, a market optimal dispatch 108,a component for balancing energy pricing 110, and a market database 114.

[0059] Each of these subsystems are discussed briefly below. Furtherdetails on the operations of each of these subsystems are discussedlater. The market user interface 102 is the gateway between the marketparticipants and the imbalance engine 100. It will be understood thateach market participant accesses the imbalance engine 100 through itsown interface 102. In a preferred embodiment, the market user interface102 is preferably a thin client web-based stand-alone sub-systemsupported by its own database storage. The market user interface isflexible and may be adapted for the addition of future additional marketcommodities with a minimum effort.

[0060] The market user interface 102 initially facilitates marketparticipant registration. For instance, when a new market participantwants to participate in the imbalance market, the market participantregisters with the imbalance engine 100. The market user interface 102additionally allows market participants to enter bid data and validationinformation. The market user interface 102 additionally visuallyrepresents the market dispatch information. The market user interface102 additionally includes security protocols whereby the marketparticipant may be verified and entered into the system as a valid user.The market user interface additionally includes the functions necessaryto enter bid data and validate the bid data. The market user interface102 presents to the market user the results of the bidding process bypresenting the market dispatch and pricing results to the market user.The market user interface 102 additionally includes the market time-linecontrol to show the participants the time sensitive information. Themarket user interface 102 additionally includes bulk upload and downloadinterfaces. Through the market user interface 102, the marketparticipant is allowed to perform bulk upload of bidding data and bulkdownload of demand information.

[0061] The market database 114 is functionally coupled to the marketuser interface 102 and is used to track and record the bidding andclearing processes of the market users. The market database 114interfaces bid data to the optimal market dispatch 108 and transfersimbalance engine dispatch orders from the optimal market dispatch 108.The data transfers are performed automatically in accordance to the timelines of the order bidding and clearing processes. It will be understoodthat the market database 114 may be implemented with any commerciallyavailable database.

[0062] The optimal market dispatch 108 is functionally coupled to themarket database 114. The optimal market dispatch 108 processes biddingdata received from market participants and distributes processeddispatch instructions and clearance data. The optimal market dispatch108 determines ex-post prices for actually provided balancing energyfrom the market generators.

[0063] The pricing engine 110 is functionally coupled to the optimalmarket dispatch and facilitates optimal pricing parameters fordispatched energy orders. The HIS/EA database 106 provides calculationsthat pertain to historical data and stores historical data for archivalpurposes. The load forecast 104 is functionally coupled to the HIS/EAdatabase and determines 5-minute average load for the next three5-minute intervals for each control area.

[0064] Referring to FIGS. 3 and 4, there is shown the imbalance enginetime-line 250. The time-line is based on the operation cycles of themarket operator and is based on fundamental market rules related to theenergy imbalance market. As previously stated, the market bidding cycleis 15 minutes starting at the top of the hour. The imbalance market isclosed 20 minutes before operational 15-minute period. Imbalance marketdispatch is performed every 5 minutes cyclically. The dispatch isperformed for three future 5-minute intervals. The same bids are usedfor the complete 15-minute period in accordance with the biddingprocess. The time-line for imbalance market dispatch is as shown in FIG.4. Dispatch instructions are sent to generating and load facilities inaccordance with the output from the imbalance engine.

[0065] It will be useful to note that there are several important issuesrelated specifically to the design of a real time energy imbalancemarket for the RTO that need to be discussed at this point. Most of theIndependent System Operators (“ISOs”) that are in operation in theUnited States (for e.g., California, PJM, New York and New England)already operate electricity markets. One feature common to these marketsis the existence of a single control area. In contrast, many of thefuture RTOs will involve multiple control areas. The present inventionhas the further advantage of having the ability to function in regionswith multiple control area environments that can further be adapted forsingle control area environments.

[0066] The RTO in such an environment operates as a virtual control areathat encompasses the existing control areas of its members. Theimbalance market will consist of multiple pricing zones and controlareas that are integrated together through dynamic scheduling. Suchdynamic scheduling requires the ability to make intra-hour scheduleadjustments. Also specific to the energy market is the system balancingrequirements which need to be addressed beyond the normal function ofautomatic generation control (“AGC”).

[0067] Referring to FIG. 5, there is shown a typical real-time marketmechanism or model for any commodity or resource. Irrespective of theparticular re-dispatch method that is employed in a real-time energyimbalance market, any imbalance in the particulars of the marketmechanism is illustrated with respect to FIG. 5. Deviations from thescheduled resource delivery can be classified into instructed deviations402 and uninstructed deviations 404. Instructed deviations 402 are theresults of participating resources responding to the RTO's dispatchinstructions. Uninstructed deviations 404 are the result of loadforecast errors, strategic behaviors, modeling limitations, etc. in theoperating plan that do not fully account for energy and temporalconstraints, failure to follow dispatch instructions, etc. Both types ofdeviations from the forecasted model affect the imbalance requirementpresented to the imbalance engine 100.

[0068] Instructed deviations 402 are price-setters while uninstructeddeviations 404 are price-takers. FIG. 5 illustrates the feedback loopbetween uninstructed deviations 404 and instructed deviations 402 in theoperation of the typical real-time market for resources.

[0069] This re-dispatch of the selected resources by the imbalanceengine 100 results in a feasible outcome. That is, no security orcontingency constraints are violated. Furthermore, if there are any suchviolations due to system condition changes, resources are re-dispatchedto remove the violations even if there is no need for real-timebalancing energy to balance the system. An exemplary handling of the biddata is illustrated with respect to FIGS. 5(a) and 5(b) along with thedetailed description of the market user interface 102.

[0070] These sub-systems are described in more details in the followingsections. The flexibility and configurability of the invention allow forfuture expansion of the basic platform to incorporate capacity basedmarkets (ancillary services), or mechanisms that further facilitateliquidity of the imbalance market.

[0071] In an exemplary embodiment, upload/download templates areprovided for the market participants to transfer information in bulk. AnXML (“Extensible Mark-up Language”) file format document will describethe file and field formats for each type of upload/download data file.Separate upload/download templates will be provided to correspond withthe data content of the market participant displays.

[0072] The main functional elements of the market user interface 102 aredescribed in more detail in the description below. One function of themarket user interface 102 is to accept bidding data from the marketparticipants. Bidding data can include the following specification ofavailable balancing energy. The market participant ID uniquelyidentifies the market participant. The type of bid, whether the bid isto adjust load or generation, is also recorded and maintained on themarket user interface. The balancing energy bid price curve isadditionally displayed to the market participant. The maximal andminimal limits for energy generation or consumption are additionallydisplayed. The maximal up and down ramp rates for energy generation areadditionally displayed on the market user interface. The validity timespecifying 15 minute time periods for which the bid is valid isadditionally displayed on the market user interface. The submitted timeis additionally displayed on the market user interface.

[0073] In a further embodiment, the bidding data can additionallyinclude more fields. For instance, single part generator/load orportfolio station/Control Area bids (within the same control area orpricing zone) are supported. Separate load and generation control areaportfolio bids must be submitted. More than one load and more than onegeneration portfolio bid can be submitted by control area. Bothgeneration and load entities can submit balancing energy bids. TheIncremental and Decremental parts of balancing energy bids are separatedby scheduled MW point. Balancing energy prices can be negative.

[0074] The set of load or generation resources contributing to theportfolio bid is static and it is defined through the Information ModelManagement system. A portfolio should contain only resources connectedat the same station bus. Otherwise, dispatch rules for internalportfolio resources must be provided as a part of a portfolio bid. Therules should determine set points for each resource as a percentagecontribution to the portfolio bid.

[0075] Balancing energy price curves are piece-wise linear monotonicallyincreasing functions. Additionally, the price curves can contain bothvertical and flat segments and may even include a completely step-wisenon-decreasing bid curve. To ensure a smoother imbalance marketoperation, piece-wise linear bid curves are preferred. The maximalnumber of segments is 20 (10 Inc and 10 Dec balancing energy segments).The minimal segment size is one megawatt. Typical balancing energy bidsare shown in FIGS. 5(a) and 5(b).

[0076] Entered bid data are validated with respect to theircompleteness, consistency and market rules. Eventual discrepancies arereported to the market participant and market operator. A bid validationprocess accesses the registration information of market participants toverify imbalance providers and static wholesale customers.

[0077] In a preferred embodiment, the load forecast 104 determines5-minute average load for the next three 5-minute intervals for eachcontrol area individually. Accordingly, all imbalance requirements andmarket participant MW set points are determined as 5-minute averagevalues. To this end, meter information, day-before forecasts, and otherelements are used to generate the imbalance forecast.

[0078] The HIS/EA database 106 is the energy measurements processing,archiving and accounting component database and provides the followingcalculations and historical data for time periods afterreal-time-operation: (1) collection, processing and integration ofcontrol area generator and tie-line analog measurements; (2) calculationof loads for the RTO and each control area; (3) collection of weatherdata that may be required for very short-term load forecasts andimbalance energy forecasts; (4) calculation of control areas ACE,frequency bias, inadvertent energy and net interchange; (5) collection,tracking and performance calculation of unit response to imbalancecontrol signals over an extended period of time necessary to track unitcontrol performance and to use this data to predict the response interms of ramping rates, overshoot, gain and other performance trackingmeasures; (6) collection of data necessary for preparation of imbalancesettlement data; (7) support for market participants in analyzing theirlong-term performance in energy imbalance market; (8) imbalance energymarket audit support; (9) support for market monitoring; and (10) longterm archiving and off-line storage of all relevant data from theimbalance engine.

[0079] All real-time data collected from individual Control Areas viaICCP are stored in HIS/EA database 106. The ICCP is an industry standardprotocol for transmitting data to and from energy management systems.The HIS/EA is a historical database of relevant data stored for archivaland prediction purposes.

[0080] The market optimal dispatch component 108 is another coresubsystem component of the imbalance engine 100. The market optimaldispatch component 108 typically minimizes the cost of operating theimbalance market, and optimizes inter zonal balancing energy transferswhile respecting power balance constraints, balancing energy limits andinter-area transmission constraints. Transmission network losses areexplicitly modeled as loss sensitivity coefficients.

[0081] The market optimal dispatch 108 also performs re-dispatch ofgenerating units at the same time that it solves for the imbalancerequirement. By re-dispatching, the imbalance engine 100 provides theoptimal solution for all bids (Inc and Dec) while providing theimbalance requirement and preventing flow gate congestion within theenergy network. The imbalance market operator is able to switch ON andOFF the re-dispatch feature. In one embodiment, when the re-dispatch isdisabled, if the RTO wide imbalance requirement is for incrementalenergy (“Inc”), then only Inc movements will be allowed, and if the RTOimbalance requirement is for decremental energy (“Dec”), then only Decmovements will be allowed.

[0082] The results of market optimal dispatch 108 are as follows. Theimbalance market clearing price (“MCP”) is set by the market optimaldispatch. The optimal schedule for net interchange correction for eachcontrol area is also set. The optimal set point for each marketparticipant is also set by the market optimal dispatch. The optimal LMPfor load and generation for each control area and price zone and eachmarket participant is set by the market optimal dispatch.

[0083] The imbalance engine 100 will operate using software designed forLMP calculations. In one embodiment, the number of nodes and networkmodel employed will be simplified so that the engine effectivelyoperates as a zonal pricing engine. The simplified representation may beextended to allow a detailed representation of the transmission systemwith accompanying LMPs for each node represented in the model.

[0084] The imbalance market optimization objective is considered as apart of the overall optimization of system operation. The imbalancemarket is situated between the bilateral energy market (that is,pre-arranged energy MW exchanges at agreed prices as opposed toreal-time imbalance spot market pricing) and automatic generationcontrol (the actual transfer of energy). Balancing energy is thegeneration of variations around bilaterally scheduled energy values tosatisfy system load. Conceptually, the imbalance market is consistentwith, but in addition to, the bilateral energy market, and settlementand billing system.

[0085] The approach to the Imbalance Engine is hereby described. Theoptimization objective is to minimize total imbalance market costs tothe RTO by providing optimal balancing energy prices to marketparticipants. If a generator provides Dec balancing energy then costspresent its pay back to the RTO, (In this model, the generator receivesfull payment for all of the amount of MW nominally scheduled. Theypayback to the RTO reflects the fact that not all of the nominallyscheduled MW is delivered is delivered when the Dec bid is accepted) Ifa generator is providing Inc balancing energy then costs present itspayment from the RTO. The imbalance engine 100 employs the Inc and Decbid amounts to cover the imbalance (variation from scheduling). (SeeFIG. 6).

[0086] Therefore, the minimization objective function is:$\begin{matrix}{{\sum\limits_{stp}{\sum\limits_{m\quad p}{{BidCost}\quad ({BidMW})}}} = {\sum\limits_{stp}{\sum\limits_{m\quad p}\left( {{{IncPayment}\quad ({IncMW})} - {{DecPayback}({DecMW})}} \right)}}} & (1)\end{matrix}$

[0087] Where:

[0088] mp is the unique Market Participant identification;

[0089] stp is the resource type set (valid values: GEN for a generation,LD for a load); BidMW is the MW point for the Market Participant mp;

[0090] BidCost(BidMW) is the bid cost at the BidMW point;

[0091] IncPayment(IncMW) is the payment for IncMW of Inc balancingenergy; and

[0092] DecPayback(DecMW) is the pay back for DecMW of Dec balancingenergy.

[0093] The RTO imbalance requirement is calculated every 5 minutes asthe sum of all control area 5-minute imbalance requirements includingschedule ramping rules:${ImbReq}_{5\quad \min}^{ARTO} = {\sum\limits_{ControLArea}{{ImbReq}_{5\quad \min}^{CA}.}}$

[0094] The control area 5-minute imbalance requirement is calculated asthe difference between control area 5-minute load forecast and totalcontrol area scheduled generation and bilaterally scheduled interchange.The last 5-minute ACE averages and imbalance biases are added for eachControl Area: $\begin{matrix}{{ImbReq}_{5\quad \min}^{CA} = {{LF}_{5\quad \min}^{CA} - {\sum\limits_{stp}{\sum\limits_{m\quad p}{SchedMW}_{5\quad \min}}} - {ACE}_{5\quad \min}^{CA} + {ImbBias}_{5\quad \min}^{CA} - {ImbCA}_{5\quad \min}^{CA}}} & (2)\end{matrix}$

[0095] Where:

[0096] ImbReq_(5 min) ^(ARTO) is the total RTO imbalance requirement;

[0097] ImbReq_(5 min) ^(CA) is the Control Area imbalance requirement;

[0098] LF_(5 min) ^(CA) is the Control Area 5-minute load forecast;

[0099] SchedMW_(5 min) is the scheduled bilateral energy with alreadyincluded transmission losses and bilaterally scheduled Interchange;

[0100] ACE_(5 min) ^(CA) is the Control Area last 5-minute average ACE;

[0101] ImbBias_(5 min) ^(CA) is the Control Area 5-minute ImbalanceBias; and

[0102] ImbCA_(5 min) ^(CA) is the Control Area 5-minute ImbalanceCallable Reserve.

[0103] The control area ACE represents specific control arearequirements with respect to its actual operating conditions.Additionally, each control area can set an imbalance bias as anadditional (positive or negative) request for balancing energy.Potentially the imbalance bias can be used for control areaself-balancing purposes. All of these data are inputs to the imbalanceengine provided by the control area EMS interfaces.

[0104] The total RTO imbalance requirement to be dispatchedImbReq_(5 min) ^(ARTO) is filtered with weighting factors for someprevious, the current and the next 5 minute values. Weightingcoefficients associated with past values (up to 5 steps) are variableswhich can be entered at the market operator interface by the MarketOperator. The default values are 20% for one previous, 60% for currentand 20% for the next 5-minute interval.

[0105] The non-filtered imbalance requirement (0%, 100%, 0%) is thedefault option. The RTO balancing energy requirement is satisfied usingall available resources: $\begin{matrix}{{\sum\limits_{stp}{\sum\limits_{m\quad p}{\left( {1 - {LosFac}} \right) \cdot {BidMW}}}} = {ImbReq}_{5\quad \min}^{ARTO}} & (3)\end{matrix}$

[0106] The energy balance constraint takes into account the transmissionnetwork losses by normalizing generation and load MW values with thecorresponding loss sensitivity factors, LossFac. The transmissionnetwork losses differentiate balancing energy prices for generators andloads to provide financial covering for network losses.

[0107] An exemplary time diagram for an imbalance requirement is shownin FIG. 7. The line 702 shows the bilateral schedule, that is, thepre-arranged energy schedule generated one or more days prior. Theforecast line 704 shows the actual five minute real time forecast. Thearea between the curves 706 where the schedule line 702 exceeds theforecast line 704 illustrates Dec imbalance and the area between thecurves 708 where the forecast line 704 exceeds the schedule line 702illustrates Inc imbalance.

[0108] Effective dispatch limits for balancing energy are determined asthe most narrow of the submitted generation limits and the possiblechanges around the actual operating point during the 2 minutes intervalwith the submitted ramp rates. Formally:

EffMin≦BidMW≦EffMax  (4)

[0109] for all bids.

[0110] Where:

[0111] EffMin=max {BidMin, ActMW−RampRate·2 min} is the effectiveminimal limit;

[0112] EffMax=min {BidMax, ActMW+RampRate·2 min} is the effectivemaximal limit;

[0113] BidMW is the balancing energy amount;

[0114] ActMW is the actual generation

[0115] BidMin is the minimal generation limit

[0116] BidMax is the maximal generation limit.

[0117] The transmission losses have an impact on the overall imbalancemarket operation. For example, the impact on market clearing pricesconsists of the following. The optimal imbalance market clearing processconsists of the following problem:${\min {\sum\limits_{stp}{\sum\limits_{m\quad p}{{BidCost}\quad ({BidMW})\quad {subject}\quad {{to}:{\sum\limits_{stp}{\sum\limits_{m\quad p}{\left( {1 - {LosFac}} \right) \cdot {BidMW}}}}}}}}} = {{ImbReq}_{5\quad \min}^{ARTO}.}$

[0118] Using the Lagrange function and market clearing price (MCP) thisproblem can be transformed into:${\min \left\{ {\sum\limits_{stp}{\sum\limits_{m\quad p}\left\lbrack {{{BidCost}\quad ({BidMW})} - {{MCP} \cdot \left( {1 - {LosFac}} \right) \cdot {BidMW}}} \right\rbrack}} \right\}} + {{MCP} \cdot {ImbReq}_{5\quad \min}^{ARTO}}$

[0119] The optimality conditions:${\frac{{\partial{BidCost}}\quad ({BidMW})}{\partial{BidMW}} - {{MCP} \cdot \left( {1 - {LosFac}} \right)}} = 0$

[0120] can be expressed as:${MCP} = {\frac{1}{1 - {LosFac}} \cdot {\frac{{\partial{BidCost}}\quad ({BidMW})}{\partial{BidMW}}.}}$

[0121] The above condition must be satisfied for each marketparticipant. The market clearing price will increase because of networklosses. There is an influence of network losses on locational marginalprices that is dependent on corresponding loss sensitivity factorsrepresenting transmission network losses. Each portfolio or single bidhas its own loss sensitivity factor with respect to the reference nodein the RTO.

[0122] Loss sensitivity factors, LossFac, are calculated using areference bus approach. That is, the generation at the reference busmoves whenever an increment is made at a generating unit. This change ingeneration output causes a change in losses, too. The power balance canbe expressed as:

ΔP _(gen) +ΔP _(ref) =ΔP _(loss).

[0123] To calculate the corresponding loss sensitivity factor:${LosFac} = {\frac{\Delta \quad P_{loss}}{\Delta \quad P_{gen}} = {1 + \frac{\Delta \quad P_{ref}}{\Delta \quad P_{gen}}}}$

[0124] all we need is the coefficient:$\beta = {\frac{\Delta \quad P_{ref}}{\Delta \quad P_{gen}}.}$

[0125] These coefficients can be calculated for all Market Participantsusing Jacobian matrix J of the Power Flow solution: $\begin{bmatrix}\frac{\partial P_{ref}}{\partial P_{g1}} \\\frac{\partial P_{ref}}{\partial P_{g2}} \\\vdots \\\frac{\partial P_{ref}}{\partial P_{gN}}\end{bmatrix} = {\left\lbrack J^{T} \right\rbrack^{- 1} \cdot \begin{bmatrix}\frac{\partial P_{ref}}{\partial\theta_{1}} \\\frac{\partial P_{ref}}{\partial\theta_{2}} \\\vdots \\\frac{\partial P_{ref}}{\partial\theta_{N}}\end{bmatrix}}$

[0126] The loss sensitivity factors are calculated by the losscalculator component. The inputs to the loss calculator are providedfrom a standard Power Flow Inter control area/price zone flows areoptimized while satisfying flowgate operating limits in both directions.

FG _(l) ≦FG _(l) ≦{overscore (FG)} _(l)  (4)

[0127] The flowgate flow model is in incremental form around scheduledor real-time values. Energy transfer flows are presented as a DC modelusing distribution factors: $\begin{matrix}{{FG}_{l} = {{FG}_{l}^{S} + {\sum\limits_{stp}{\sum\limits_{m\quad p}{{SF}_{{m\quad p},l} \cdot {BidMW}_{m\quad p}}}}}} & (5)\end{matrix}$

[0128] where:

[0129] FG_(l) and BidMW_(mp) are the optimal power flow for flowgate land the optimal generation output of the Market Participant mp,respectively

[0130] SF_(mpt,l) is the shift factor for the MW injection of the MarketParticipant mp on the flowgate l

[0131]FG _(l) and {overscore (FG)}_(l) are MW line flow limits for theflowgate l in direct and reverse directions

[0132] FG_(l) ^(s) is the set point for power flow at the flowgate l.The actual flowgate power flows will be used.

[0133] The economic transfer of power through control areas within thecontext of imbalance energy requirements of all control areas in theleast cost fashion is a necessity. Since market generators havesubmitted bids for balancing energy, they have volunteered to modify theoutput of their units. They are willing sellers or buyers at a price ata particular point in time. It should be of no concern to the marketgenerators that some portion of the control area energy may flow to orcome from a different control area. More importantly without theconvergence of imbalance price between control areas, we cannot claim tohave an integrated market.

[0134] The imbalance engine of the present invention recognizestransmission line loading relief (“TLR”) called by the securitycoordinator(s) to curtail selected energy transfers between ControlAreas to relieve overloads on congested flowgates. The imbalance enginefurther makes available to the security coordinators the magnitude andexpected magnitude of those schedules so that the security coordinatorscan make informed decisions about how much of the energy transfers needto be curtailed.

[0135] The imbalance market clearing process is based on non-linearDantzig-Wolfe decomposition supported by the revised simplex method.Dantzig-Wolfe is a decomposition algorithm for linear programmingsolutions. The decomposition of the market dispatch problem results inthe master problem related to overall imbalance market optimization, anda set of sub-problems related to the individual market participantoptimizations.

[0136] To solve the master problem, the revised simplex method isemployed. The results provide optimal market clearing prices based onsub-problem solutions found in previous iterations. These prices arepassed to the sub-problems as market coordination signals. The new setof sub-problems are solved and the solutions are returned back to themaster problem. These responses are compared to the market requirementsfor Inc and Dec balancing energy requirements. Any imbalance causesupdates for market prices leading to supply/demand balance for eachmarket product.

[0137] Market participant optimization provides its best response toposted market prices. These sub-problems present a multiple productco-optimization from a single market participant's point of view. Thesub-problems absorb all economic and physical characteristics specificto each market participant.

[0138] In accordance to the Dantzig-Wolfe approach, optimality must beimproved at each iteration. Otherwise, the optimal solution of themarket dispatch problem has been achieved. Tied bids will be dispatchedpro rata, i.e. proportionally to the length of tied bid MW segments. Thepro rata bids will be dispatched to the market participant

[0139] The optimal results include both market clearing prices andoptimal balancing energy set points for each market participant. Theoptimal results consist of the desired 5-minute average values that areexpected to be implemented in the future time. The implementation of theimbalance market dispatch results will be supported by standard rampingrules applied in accordance to market participant dynamics. Ramping willstart 1 minute before the start of the operational 5-minute interval.This ramping rule will provide balancing energy service as it isdispatched by the imbalance market. These effects are illustrated in thetime diagram of FIG. 8.

[0140] The imbalance engine 100 operates normally when it is inside itsoperating limits. Certain checks must be made to determine whether theimbalance engine remains with its operating limits. The followingoperational checks are applied in the specified order:

[0141] No Market Participants—To operate the imbalance market at leastone valid bid must be submitted. The market cannot operate without bids.

[0142] Imbalance Engine does not operate properly—If the imbalanceengine is down for 15 minutes or less then the imbalance engine uses thelast valid solution price(s).

[0143] After more than 15 minutes of down time, manual intervention bythe RTO operator will be required.

[0144] Imbalance Requirement not feasible—If there is not enough Inc orDec bid capacity to cover the actual imbalance requirement, then theimbalance requirement is set to the maximal or minimal possible level.Regular market clearing will be performed and provided optimal resultsused as dispatch instructions.

[0145] Inter Control Area flow limits not feasible—If inter control areaflow limits do not provide enough transfer capacity to cover the energyimbalance requirement, then the imbalance requirement will be satisfiedas much as possible with minimal violation of inter control area flowlimits. The inter control area flow limits will have higher prioritythan the imbalance requirement. Regular imbalance market clearing willbe provided with minimal changes of the inter control area flow limitsand/or imbalance requirement to provide feasibility. The LMPs willinclude both network losses and network congestion in a regular way.

[0146] If any of the above checks are positive, then appropriate warningmessage are created.

[0147] Balancing energy pricing is based on the imbalance marketclearing results. These ex-ante prices are modified before being usedfor billing purposes depending on ex-post quantities of balancingenergy.

[0148] The imbalance market clearing provides optimal balancing energyprices and quantities under expected operational conditions. In thepresence of transmission network losses and eventual flow gatecongestion, each market participant will have different balancing energyprices.

[0149] Formally, the optimal imbalance market clearing process consistsof the following problem:$\min {\sum\limits_{stp}{\sum\limits_{m\quad p}{{BidCost}\quad \left( {BidMW}_{m\quad p} \right)}}}$

[0150] subject to:

[0151] power balance:${\sum\limits_{stp}{\sum\limits_{m\quad p}{\left( {1 - {LosFac}_{m\quad p}} \right) \cdot {BidMW}_{m\quad p}}}} = {ImbReq}_{5\quad \min}^{ARTO}$

[0152] flowgate constraints:${{\underset{\_}{FG}}_{l} \leq {FG}_{l}} = {{{FG}_{l}^{S} + {\sum\limits_{stp}{\sum\limits_{m\quad p}{{SF}_{{m\quad p},l} \cdot {BidMW}_{m\quad p}}}}} \leq {\overset{\_}{FG}}_{l}}$

[0153] Using Lagrange function, this problem can be transformed into:$\left. {\min \left\{ {{\sum\limits_{stp}{\sum\limits_{m\quad p}\left\lbrack \left( {{{BidCost}\quad \left( {BidMW}_{m\quad p} \right)} - {{MCP} \cdot \left( {1 - {LosFac}_{m\quad p}} \right) \cdot {BidMW}_{m\quad p}}} \right) \right)}} + {\sum\limits_{i}{{FCP}_{l} \cdot {SF}_{{m\quad p},l} \cdot {BidMW}_{m\quad p}}}} \right\rbrack} \right\} + {{con}.}$

[0154] The optimality conditions are satisfied if each marketparticipant operates under its locational marginal price determined by:$\begin{matrix}{{LMP}_{m\quad p} = {{\left( {1 - {LossFac}_{m\quad p}} \right) \cdot {MCP}} - {\sum\limits_{i}{{FCP}_{l} \cdot {SF}_{{m\quad p},l}}}}} & (6)\end{matrix}$

[0155] Where:

[0156] LMP_(mp) is the locational marginal price for the marketparticipant mp;

[0157] MCP is the balancing energy market clearing Price (result ofimbalance market dispatch);

[0158] LossFac_(mp) is the loss sensitivity factor for the marketparticipant mp;

[0159] SF_(mp,l) is the shift factor for the MW injection of the marketparticipant mp on the flow gate l; and

[0160] FCP_(l) is the shadow price for the flow gate l constraint(result of imbalance market dispatch).

[0161] Resulting locational marginal prices are the optimal pricesignals for both loads and generators from the market participant pointof view. With these locational marginal prices, the profit is maximal atdispatched set point for each market participant individually.

[0162] For each market participant, the actually provided increase anddecrease balancing energy services are calculated every five minutes.Provided Inc balancing energy for generation market participants iscalculated as the difference between actual and scheduled energygenerations and for load market participants as the difference betweenscheduled and actual energy consumptions. On the other hand, the Decbalancing energy for generation market participants is calculated as thedifference between scheduled and actual energy generations, and for loadmarket participants as the difference between actual and scheduledenergy consumptions.

[0163] The ex-ante locational marginal prices (“LMP”) are modifiedafter-the-fact to provide billing prices. The modifications areperformed for each market participant individually depending onbalancing energy actually provided. For generating market participants,the billing price calculations are based on the following rules:

[0164] If the balancing energy service actually provided, is higher thanthe optimal dispatch set point then ex-ante locational marginal price isapplied as the billing price for each marginal market participant. FIG.9 illustrates the appropriate billing price for this situation. If thebalancing energy service actually provided is lower than the optimaldispatch set point then the ex-post as-bid price is applied as thebilling price for marginal market participant. FIG. 10 illustrates theappropriate billing price for this situation. For a non-marginal marketparticipant (dispatched on its minimal or maximal limit) the ex-antelocational marginal price is applied as the billing price for actualbalancing energy independently of uninstructed deviations from thedispatched set point. FIG. 11 illustrates the appropriate billing pricefor this situation.

[0165] These rules set the billing price for marginal marketparticipants to be the lower of either the ex-ante locational marginalprice and the ex-post as-bid price. This means that any marketparticipant cannot directly control the balancing energy price in anycase. Uninstructed reductions in balancing energy service below thedispatched set point will cause the decreasing of the billing price,while uninstructed balancing energy service increasing above dispatchedset point will not be awarded by any increasing of the billing price. Itwill be apparent to one of ordinary skill in the art that similarpricing rules will be used for load market participants.

[0166] Additionally, for market non-participants the following rules canbe applied:

[0167] If movement is in the same direction as the Imbalance Marketrequirement, then the provided support will be compensated by settingthe Billing Price equal to some percentage of the Locational MarginalPrice. For Inc balancing energy, a percentage less then one hundred willbe used (the default value is 90%), and for Dec balancing energy, apercentage higher then one hundred will be used (the default value is110%). This represents the payment to the RTO. To be fully compensated(at 100%) it is necessary for the generator to be a market participantand to contribute in market clearing process and price setting.

[0168] If movement is in the opposite direction to the Imbalance Marketrequirement, then the imbalance disturbance will be charged at theLocational Marginal Price for both Inc and Dec energy imbalances. Thisrule will be applied in charging for balancing energy to all entitiescausing system imbalance.

[0169] In any case, to provide settlement prices, the 5 minute BillingPrices for each Market Participant are averaged during one hour usingthe following formula: $\begin{matrix}{{BP}_{m\quad p}^{T} = \frac{\sum\limits_{t \in T}\left( {{{IncMW}_{t} \cdot {BP}_{m\quad p}^{t}} - {{DecMW}_{t} \cdot {BP}_{m\quad p}^{t}}} \right)}{\sum\limits_{t \in T}\left( \left| {IncMW}_{t} \middle| {+ \left| {DecMW}_{t} \right|} \right. \right)}} & (7)\end{matrix}$

[0170] Where:

[0171] BP_(mp) ^(T) is the settlement Billing Price for the MarketParticipant mp for the period T (one hour);

[0172] IncMW_(t) and DecMW_(t) is provided Inc and Dec balancing energyfor the time interval t (5 minutes); and

[0173] BP_(mp) ^(t) is the Billing Price for the Market Participant mpfor the time interval t (5 minutes).

[0174] If there is no network congestion then all market participantsbelonging to the same pricing zone will have the same price.Additionally, hourly average price for imbalance requirement for eachcontrol area will be calculated as follows:${{BalCost}\quad}_{\quad {CA}}^{T} = {\sum\limits_{t \in T}{\frac{{ImbReq}_{5\quad \min}^{CA}}{T} \cdot {MCP}_{5\quad \min}}}$

[0175] Where:

[0176] BalCost_(CA) ^(T) is the balancing energy cost for the controlarea for the period T (one hour);

[0177] ImbReq_(5 min) ^(CA) is the imbalance requirement of the controlarea for the time interval t (5 minutes); and

[0178] MCP_(5 min) is the market clearing price for the RTO for the timeinterval t (5 minutes).

[0179] It will be noted that for Inc balancing service, generators arepaid by the RTO. Conversely, for Dec balancing service, generators payback to the RTO. This is illustrated in FIG. 12.

[0180] For load market participants, money flows in the oppositedirection to what heretofore has been described. The averaged billingprices and balancing energy total quantities are passed to aconventional settlement system for billing purposes.

[0181] Furthermore, in addition to the above described pay-as-MCPpricing scheme, the pay-as-bid balancing energy pricing will beprovided. It will be noted that the operator may select the pricingscheme.

[0182] Imbalance market clearing provides optimal balancing energyprices and quantities under expected operational conditions. Instead ofthe locational marginal price, the as-bid price is determined bycomparing the dispatched set point to the bid curve for each marketparticipant individually.

[0183] For each marginal market participant, the as-bid price is equalto its locational marginal price because the dispatched balancing energyprice and quantity are matched on the bid curve inside the dispatchlimits. This price will include network losses and eventual networkcongestion. Referring to FIG. 13, there is shown the Inc as-bid priceand Inc price curve, and the Dec as-bid price and the Dec price curveagainst the MW axis for each market participant.

[0184] For the non-marginal market participant, the dispatched set pointis on the minimal or the maximal balancing energy limit. The ex-anteas-bid price is determined by comparing these extreme set points withthe submitted bid curve. In this case, LMP for Inc balancing energy ishigher, and LMP for Dec balancing energy is lower than the appropriateex-ante as-bid prices. This is illustrated in FIG. 14.

[0185] Ex-ante as-bid prices are still optimal price signals for bothloads and generators from the market participant's point of view. Underthese prices, the profit is maximal at the dispatched set point for eachmarket participant individually. Non-marginal market participants areblocked by balancing energy limits from following the price movementfrom as-bid to the LMP level.

[0186] The actually provided Inc and Dec balancing energy services arecalculated every 5 minutes for each market participant. The provided Incbalancing energy for generation market participants is calculated as thedifference between actual and scheduled energy generation and for loadmarket participants as the difference between scheduled and actualenergy consumption. On the other hand, the Dec balancing energy forgeneration market participants is calculated as the difference betweenscheduled and actual energy generations, and for load marketparticipants as the difference between actual and scheduled energyconsumptions.

[0187] The ex-ante as-bid prices are modified after-the-fact to providebilling prices. The modifications are performed for each marketparticipant individually depending on the actually provided balancingenergy. For generating market participants, the billing pricecalculations are based on the following rules:

[0188] If the actually provided Inc or Dec balancing energy service ishigher than the optimal dispatch set point then operating costs will becovered to the optimal dispatch set point, and Ex-Ante As-Bid Price isapplied above the optimal dispatch set point. This is illustrated inFIG. 15. The billing price is calculated as follows:

[0189] Calculate costs as area under bid curve to the ex-ante dispatchedpoint;

[0190] Calculate payment above ex-ante dispatched point using ex-anteAs-bid price;

[0191] Calculate total payment as sum of two above;

[0192] Calculate billing price as ratio of total costs and actualbalancing energy.

[0193] If actually provided Inc or Dec balancing energy service is lowerthan the optimal dispatch set point then actual operating costs arecovered only. This is illustrated in FIG. 16. The billing price iscalculated by the following method:

[0194] Calculate costs as area under the bid curve to the actual point;Calculate billing price as ratio of total costs and actual balancingenergy.

[0195] These rules set the billing price to be limited by ex-ante as-bidPrices. That is, any market participant cannot directly control thebalancing energy price in any case. Uninstructed reduction in balancingenergy service below dispatched set point will cause decreasing of thebilling price, while uninstructed balancing energy service increasingabove dispatched set point will not be awarded by increasing of thebilling price. For load market participants, similar pricing rules willbe used.

[0196] Additionally, for the market non-participants the following rulescan be applied:

[0197] If movement is in the same direction as the imbalance marketrequirement, then the provided support will be compensated by settingthe billing price equal to some percentage of the locational marginalprice. For Inc balancing energy, a percentage less then one hundred willbe used (the default value is 90%), and for Dec balancing energy, apercentage higher then one hundred will be used for calculating paymentto the RTO (the default value is 110%). To be fully compensated (at100%) it is necessary for the generator to participate in the market andto contribute in market clearing process and price setting.

[0198] If movement is in the opposite direction to imbalance marketrequirement, then the imbalance disturbance will be charged at thelocational marginal price for both Inc and Dec energy imbalances. Thisrule will be applied in charging for balancing energy to all entitiescausing system imbalance.

[0199] In either case, to provide settlement prices, the five minutebilling prices for each market participant are averaged during one hourusing the following formula: $\begin{matrix}{{BP}_{m\quad p}^{T} = \frac{\sum\limits_{t \in T}\left( {{{IncMW}_{t} \cdot {BP}_{m\quad p}^{t}} - {{DecMW}_{t} \cdot {BP}_{m\quad p}^{t}}} \right)}{\sum\limits_{t \in T}\left( \left| {IncMW}_{t} \middle| {+ \left| {DecMW}_{t} \right|} \right. \right)}} & (7)\end{matrix}$

[0200] Where:

[0201] BP_(mp) ^(T) is the settlement billing price for the marketparticipant mp for the period T (one hour);

[0202] IncMW_(t) and DecMW_(t) is provided Inc and Dec balancing energyfor the time interval t (5 minutes);

[0203] BP_(mp) ^(t) is the billing price for the market participant mpfor the time interval t (5 minutes).

[0204] If there is no network congestion, then all market participantsbelonging to the same pricing zone will have the same price.Additionally, hourly average costs for imbalance requirements for eachcontrol area will be calculated as follows:${BalCost}_{CA}^{T} = {\sum\limits_{t \in T}\quad {\frac{{ImbReq}_{5\quad \min}^{CA}}{T} \cdot {MCP}_{5\quad \min}}}$

[0205] Where:

[0206] BalCost_(CA) ^(T) is the balancing energy cost for the controlarea for the period T (one hour);

[0207] ImbReq_(5 min) ^(CA) is the imbalance requirement of the controlarea for the time interval t (5 minutes); and

[0208] MCP_(5 min) is the market clearing price for the RTO for the timeinterval t (5 minutes).

[0209] The averaged billing prices and balancing energy total quantitiesfor each market participant are passed to the settlement system forbilling purposes.

[0210] In a further embodiment of the present invention, it will beunderstood that instead of the previously described pricing schemes,i.e. pay-as-MCP and pay-as-bid, the two settlement pricing scheme forbalancing energy can also be employed. In this approach, imbalancemarket stability and efficiency is guaranteed with minimal opportunitiesfor gaming by the market participants. This is an essential requirement,especially for real-time markets.

[0211] The two settlement pricing scheme combines both ex-ante andex-post pricing approaches into a consistent two part billing systemcapable of determining optimal prices for both instructed anduninstructed deviations including network congestion pricing. In thefirst step, the ex-ante optimal market clearing price and the dispatchedset points are provided. These instructed balancing energy quantitiesare priced by ex-ante locational marginal prices as the contractedobligation for each market participant.

[0212] After-the-fact prices for actual provisions are determined usingthe balancing energy measurements. These ex-post prices are based on anoptimal evaluation of the actual conditions and quantities usingafter-the-fact optimal dispatch solutions. This dispatch presents theimbalance market sensitivity analysis around the actual points includingthe flow gate power flow operating limits. The ex-post optimal marketclearing price is applied to uninstructed deviations.

[0213] The two settlement pricing approach consists of the followingsteps:

[0214] Perform market clearing using the as-bid pricing approach;

[0215] Implement the ex-ante dispatch instructions;

[0216] Collect actual data for balancing energy provided during 5-minuteinterval for each market participant;

[0217] Select a set of market participants qualified for setting ofex-post prices in accordance to market performance criteria;

[0218] Calculate actual total RTO balancing energy and set it as the RTOimbalance requirement;

[0219] Set market participant bid ranges using narrow limits aroundafter-the-fact provisions of balancing energy;

[0220] Set flow gate power flow limits to cover actual power flow;

[0221] Execute after-the-fact imbalance market dispatch using submittedbalancing energy bids;

[0222] Apply the two settlement pricing scheme:

[0223] Up to ex-ante dispatch set points apply ex-ante locationalmarginal prices as billing prices

[0224] For after-the-fact deviations around ex-ante dispatch set points,apply ex-post locational marginal prices as billing prices.

[0225] The optimal market dispatch 108 determines ex-post prices foractually provided balancing energy. These prices can be used todetermine the pay-as-LMP or pay-as-bid purposes in the same way.

[0226] After-the-fact imbalance market clearing will provide ex-postprices for actual balancing energy service. Both forward dispatch andactually performed operation will be evaluated from overall marketeconomic efficiency point of view.

[0227] The control area in accordance with NERC procedures willcalculate inadvertent energy for each control area. In addition, themonetary value of this account will be tracked at the time of thepurchases as if it were a wholesale participant in the imbalance market.This eliminates any incentive for load serving entities to game thesystem by leaning on the inadvertent energy capabilities of the controlareas during high price periods and returning the energy at lower priceperiods.

[0228] Inadvertent energy is calculated with respect to scheduledinterchanges. All Control Areas will use 5 minute cross-ramping:starting ramping 5 minutes before, and stopping ramping 5 minutes afterthe top of the hour.

[0229] It will be understood that conventional relational databasetechnology can be used as the storage mechanism for the RTO imbalanceengine input and output. The requirement for the relational database canbe summarized as follows. The relational database should feature:

[0230] Ability to store disparate types of data, which are interrelatedand possibly dependent. The data model (schema) can be easily modified,with the ability to add or delete structure and data as necessary. Theapplication design interface supports standard languages, tools andinterfaces.

[0231] Scalability in terms of number of users and amount/type of datastored. The access time is consistent across different database sizes.Maximum database size is limited only by the underlying storage medium.

[0232] Integrated data storage management.

[0233] Tunable database performance within the platform/operatingsystem.

[0234] Upwardly compatibility Platform/operating

[0235] Backup and recovery capabilities integrated into databasemanagement system (“DBMS”) core.

[0236] Support for multiple users with different levels of access. Forexample, allow individual participants to view only their data, but RTOoperators can view all data. The user management system is integratedwith DBMS, allowing programmatic user support.

[0237] Referring to FIG. 17, there is shown an object oriented view ofthe data model to be used by the imbalance engine 100 of the presentinvention. This object-oriented view of the data model is in theInformation Model Management system. Most objects will have staticattributes defined The Information Model Management system provides themeans of easily updating and/or extending the data model.

[0238] In the exemplary embodiment described herein, the real-timeimbalance engine database is an Oracle RDBMS. The RDBMS tables typicallyhave a one-to-one correspondence to the objects shown in the figure, butthere will be a few exceptions. The static data, defined in theInformation Model Management system objects is transferred to theImbalance Engine RDBMS tables during the population step. In addition tothe static data, the Imbalance Engine RDBMS tables will have columns forany dynamic data that needs to be kept persistent and/or displayed.

[0239] Referring again to FIG. 2, the imbalance engine 100 of thepresent invention interfaces to various subsystems. In an exemplaryembodiment, the imbalance engine interfaces to the following subsystems:

[0240] Tagging/Scheduling

[0241] NERC Interchange Distribution Calculator (IDC)

[0242] Loss Calculator

[0243] Load Forecast

[0244] Individual Control Area EMS systems via ICCP

[0245] Market Participant entered information via MUI

[0246] Weather center/data

[0247] Security Coordinators

[0248] Outage Scheduler

[0249] Settlement & Billing

[0250] It will be understood that the above list of subsystems is notexhaustive of the interfaces that the imbalance engine interfaces with.It will be additionally understood that any of the above listedsubsystems can be integrated with the imbalance engine 100 of thepresent invention without deviating from the spirit and scope of thepresent invention.

[0251] These interfaces are described in further detail below. Referringto FIG. 18, there is shown a schematic diagram of the relationshipbetween the imbalance engine database and the interface databases.

[0252] In a preferred embodiment, the imbalance engine database is anOracle database available commercially from Oracle Corporation ofRedwood Shores, California. All data transfers are transmitted by meansof the interfaces between two Oracle databases, except thebi-directional ICCP connection to the control area EMS systems. Theintensity and frequency of data transfers are diverse, but the followingcommon approach will be provided for all data transfers between theimbalance engine database and the interface databases:

[0253] Data interfaces are asynchronous with respect to each to other

[0254] Data transfers can be performed from different sources at thesame time

[0255] Data transfer is activated whenever source data is changed

[0256] Data is transferred into separate input tables in IE DB

[0257] Data time interval validity is part of transferred data

[0258] Last transfer IE DB time is posted

[0259] Input data can be reviewed and edited by Imbalance MarketOperator

[0260] Manually entered or modified data will be treated as new datatransfers and the time of last transfer will be updated

[0261] A data snapshot is performed automatically at Imbalance Enginerun-time whenever the last transfer time is higher then last snapshottime. The last snapshot time is updated automatically to the time of theIE DB

[0262] Working tables are used for Imbalance Market dispatch only

[0263] The Market Operator may do the following:

[0264] Activate/block data transfer,

[0265] Enter and modify data in input tables. Each data interface issupported by its own displays presenting Input Tables only,

[0266] Change data validity time,

[0267] Activate/block data snapshot.

[0268] Referring to FIG. 19, there is shown a common structure of datainterfaces, while specific details are described hereinbelow.

[0269] The market database interface is provided to transfer bid datainto the imbalance engine database whenever the imbalance market isclosed, and to transfer imbalance engine dispatch results into themarket database whenever the imbalance engine is executed. The datatransfers are performed automatically in accordance to the time-lines ofthe bidding and clearing processes. Additionally, data transfers can beactivated and blocked by the imbalance market operator.

[0270] The following data are transferred from the market user interfacedatabase into the imbalance engine database whenever the imbalancemarket is closed:

[0271] Market Participant ID

[0272] Portfolio ID, its resources and percentages of their contribution

[0273] Bid curves

[0274] Scheduled values

[0275] Bid minimal and maximal energy limits

[0276] Bid Up and Down ramp rates

[0277] Bid validity time

[0278] Such data can be reviewed and edited manually by the imbalancemarket operator.

[0279] In the opposite direction, imbalance market dispatch results forthe following three 5-minute intervals are transferred into the marketdatabase from the imbalance engine:

[0280] Time stamps

[0281] Load Forecast 5-minute values for RTO and each Control Area

[0282] Imbalance Requirement values for RTO and each Control Area

[0283] Imbalance Requirement type (Inc or Dec) for RTO and each ControlArea

[0284] Market Clearing Prices

[0285] Optimal set points for each Market Participant or portfolio

[0286] Actual after-the-fact balancing energy for each MarketParticipant

[0287] Balancing service type (Inc or Dec) for each Market Participant

[0288] Balancing energy prices for each Market Participant

[0289] These data are posted on the Market UI for Market Participantusage.

[0290] The Imbalance Market Engine retrieves from the Tagging/Schedulingsub-system the next hour schedules for all generators and loads. Thisinterface is designed as an Oracle-to-Oracle database data transfer.

[0291] The summary schedules for loads and generators inside one ControlArea are provided for each hour. The scheduled data is used forimbalance requirement calculation as well as the reference points forimbalance service calculations. The interface is designed as a standalone API. It is activated whenever bilateral scheduling checkout iscompleted (20 minutes before operational hour). The interface activationis performed by the Tagging/Scheduling sub-system. The Imbalance MarketOperator is capable of activating this interface manually. On therequest of the imbalance market operator, data for some specified marketparticipant and/or some specified hour, including future hours, can betransferred from Tagging and Scheduling.

[0292] As default, the following data is transmitted periodically everyhour for each market participant:

[0293] market participant ID including its control area/pricing zonespecification

[0294] The total scheduled MW value including all bilateral and dynamicschedules for the next hour. In a further embodiment, transmissionnetwork losses may be included into calculated scheduled values. Thecumulative values of MW are calculated for each market participant andonly these cumulative scheduled values are transmitted.

[0295] The imbalance engine 100 additionally supports entering of hourlyschedules for each market participant. These schedules are used wheneverthe tagging/scheduling sub-system is not available. These manualschedules are activated and can be edited manually by the imbalancemarket operator.

[0296] The IDC interface provides DC model data for TLRs and intercontrol area/price zone flow gates. The data transfer will be performedvia a web interface. The following data is needed for each flow gate:

[0297] Flowgate ID including source and sink control areas

[0298] Shift factors for each market participant.

[0299] The IDC Interface is activated by the IDC whenever flowgate modeldata are changed, or alternatively on imbalance market operator request.

[0300] The loss calculator provides the imbalance engine with losssensitivity factors for all market participants (control area/price zoneor individual generation/load). In a preferred embodiment, thisinterface is designed as an Oracle-to-Oracle database data transfer.

[0301] The loss calculator interface is activated by the loss calculatorwhenever loss sensitivity factors are re-calculated, or on imbalancemarket operator request.

[0302] The load forecast interface will provide 5-minute loads for thenext three 5-minute intervals for each control area. The load forecastresults are directly accessible by the imbalance engine and data istransferred automatically in accordance to the imbalance markettime-line. No manual operator intervention is needed to transfer thisdata. This interface is designed as an Oracle-to-Oracle database datatransfer.

[0303] The HIS/EA function 106 supports the imbalance engine 100 withreal time data and stores imbalance market results for marketperformance monitoring purposes. Data transfers in both directions arecyclical with 5-minute periodicity. The data transfers are activatedautomatically by source function whenever a new set of data isavailable.

[0304] Additionally, the imbalance market operator can activate/blockmanually both data transfer directions.

[0305] The HIS/EA function 106 will calculate 5-minute average valuesand transfer them into the imbalance engine database:

[0306] Control area ACE (5-minute ACE average)

[0307] Control area frequency bias component of ACE (5-minute average)

[0308] Control area net interchange (5-minute average)

[0309] Control area generation by unit (5-minute average)

[0310] Status of generation units on imbalance market control todetermine whether a unit will participate or not.

[0311] Meter values of load participating directly in the imbalancemarket (5-minute average)

[0312] Control area load (total control area load, 5-minute average,includes distribution losses)

[0313] Status of participating EMS

[0314] Control area imbalance bias (a bias applied to the imbalancedemand to manage regulation unit set points, the bias applies to thenext iteration of imbalance market)

[0315] Control area callable reserve

[0316] Inter and intra control area flowgate power flows

[0317] In the opposite direction, the imbalance engine 100 passes intothe HIS/EA database 106 the complete dispatch results for operational5-minute interval:

[0318] Time stamps

[0319] Load forecast 5-minute values for each control area and RTO

[0320] Scheduled 5-minute values for each control area and RTO

[0321] Imbalance bias values for each control area and RTO

[0322] Frequency bias values for each control area and RTO

[0323] Imbalance requirement values for each control area and RTO

[0324] Imbalance requirement type (Inc or Dec) for each control area andRTO

[0325] Market clearing prices

[0326] Optimal set points and limits for each market participant orportfolio

[0327] Scheduled values for each market participant or portfolio

[0328] Provided balancing energy for each market participant and marketnon-participant

[0329] Balancing service type (Inc or Dec) for each market participantand market non-participant

[0330] Balancing energy LMP for each market participant and marketnon-participant

[0331] Balancing energy billing price for each market participant andmarket non-participant

[0332] Flow gate power flows and limits

[0333] Flow gate shadow prices for congested flow gates.

[0334] Additionally, hourly billing prices, quantities and charges foreach market participant portfolio are passed to the HIS database forsettlement and billing purposes. These interfaces are designed asOracle-to-Oracle database data transfer in both directions.

[0335] The control area EMS systems exchange data with the imbalancemarket engine through ICCP, via EIB or other batch transfer processes.The following input and output data will be transferred through the ICCPlinks:

[0336] Input Data (through the ICCP):

[0337] Control area 1-minute average ACE for the last minute. This is aNERC CPS1 reported ACE.

[0338] Control area frequency bias component of ACE (1-minute average).This is the frequency error times the frequency bias divided by 10.Frequency error is calculated off the scheduled frequency, so time errorcorrection is already taken care of this way.

[0339] Control area generation by unit (1-minute average). This is anintegrated value every minute for all generators.

[0340] Status of generation units on imbalance market control todetermine whether a unit will participate or not.

[0341] Meter values of load participating directly in the imbalancemarket (, 1-minute average)

[0342] Control area load (total Control Area load, 1-minute average)

[0343] Status of participating EMS. If the ICCP node is up, theimbalance engine needs EMS On/Off. If the ICCP node is down, then thequality flag of the ICCP will say failed

[0344] Control area imbalance bias for the next 5-minute interval (abias applied to the imbalance demand to manage regulation unit setpoints, the bias applies to the next iteration of the imbalance market).This can be used to take care of self-supplying control areas.

[0345] Control area callable reserve that is being sent to or suppliedfrom another control area

[0346] All tie-line power flows

[0347] Flow gate power flows

[0348] Hourly net output of generation from integrated meter readings(these hourly accumulated values are compared with hourly integrated5-minute values for reporting purposes only)

[0349] Hourly meter data for load participating directly in theimbalance market (these hourly accumulated values are compared withhourly integrated 5-minute values for reporting purposes only)

[0350] Output Data (through ICCP and EIB) for the next three 5-minuteintervals:

[0351] Dynamic schedules for net interchange for each control area

[0352] Forecasted control area load for next two 5-minute intervals

[0353] Dynamic schedules for imbalance requirement for each control area

[0354] Set points for imbalance providers by portfolio and by unit

[0355] A set point for the operational 5-minute interval for imbalanceproviders by unit

[0356] Locational marginal prices of imbalance energy for imbalanceproviders by portfolio

[0357] The average hourly RTO-wide market clearing price for calculatingnetwork customers bills at the TOs.

[0358] The following input data will be transferred via EIB or otherbatch transfer processes:

[0359] Input Data (through EIB):

[0360] Generator restrictions due to must run requirements, orcongestion imposed via provision of regulation or other obligations tothe Control Area (max limits, min limits).

[0361] Adjusted quantities for LSE customers (corrected data, generallya delta adjustment by hour).

[0362] Adjustments to generator and tie-line meter data (corrected datafor settlements with generation, generally an adjustment for each5-minute interval).

[0363] It will be noted that the imbalance market operator canactivate/block manually data transfers in both directions.

[0364] The security coordinator can set inter control area flow gatepower flow limits. Additionally, balancing energy dynamic schedules canbe reported for security analysis. In both directions, data transfer isperformed via EIB sub-system.

[0365] The following data is transferred to the settlement/billingsystem:

[0366] Quantity, price and charge for each 5-minute interval for allgenerators (market participants and market non-participants)

[0367] Quantity, price and charge for each 5-minute interval for allloads that are participating in the imbalance market

[0368] Billing quantity, price and charge for each hour for allgenerators (market participants and market non-participants)

[0369] Billing quantity, price and charge for each hour for all loadsthat are participating in the imbalance market

[0370] The quantities and prices of balancing energy are passed to thesettlement system via EIB for billing purposes only.

[0371] The above described embodiments are merely exemplary. Those ofordinary skill in the art may readily devise their own implementationsthat incorporate the principles of the present invention and fall withinthe spirit and scope thereof.

What is claimed is:
 1. A system for balancing the load requirements forenergy imbalance in an energy trading market, said system comprising: aplurality of market user interfaces, each market user interfacereceiving from a plurality of market participants supply and demandrequirements for imbalance energy; and an imbalance engine coupled tosaid plurality of market user interfaces for determining optimal marketdispatch corresponding to said supply and demand requirements.
 2. Thesystem of claim 1, wherein said optimal market dispatch is calculated inreal-time.
 3. The system of claim 2, wherein said optimal marketdispatch is calculated in real-time for a plurality of control areas. 4.The system of claim 1, wherein said optimal market dispatch iscalculated in five minute intervals.
 5. The system of claim 1, whereinsaid market user interface further receives pricing information fromsaid market participants.
 6. The system of claim 5, wherein said pricinginformation is in a step-wise price curve.
 7. The system of claim 5,wherein said pricing information is in a piecewise linear price curveform.
 8. The system of claim 1, wherein said market user interfacereceives pricing information from said market participants in fixed timeintervals.
 9. The system of claim 8, wherein said fixed time interval isfifteen minutes.
 10. The system of claim 1, wherein said imbalanceengine further compromises: a market database; an optimal marketdispatch coupled to said market database; a load forecast coupled tosaid optimal market dispatch; a HIS database coupled to said loadforecast; a pricing engine coupled to said optimal market dispatch. 11.The system of claim 10, wherein said market database tracks bidding datafrom said market participants.
 12. The system of claim 10, wherein saidoptimal market dispatch processes bidding data from said marketparticipants.
 13. The system of claim 10, wherein said optimal marketdispatch processes clearance data from said market participants.
 14. Thesystem of claim 13, wherein said optimal market dispatch furtherperforms clearing of imbalance energy bids across a plurality of controlareas.
 15. The system of claim 10, wherein said pricing engine generatesoptimal pricing parameters for dispatched instructions.